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The development of computer software as a tool to generate visual displays has led to an 
overall expansion of automated computer generated images in the aerospace industry. 
These visual overlays are generated by combining raw data with pre-existing data on the 
object or objects being analyzed on the screen. The National Aeronautics and Space 
Administration (NASA) uses this computer software to generate onscreen overlays when a 
Visiting Vehicle (VV) is berthing with the International Space Station (ISS). In order for 
Mission Control Center personnel to be a contributing factor in the VV berthing process, 
computer software similar to that on the ISS must be readily available on the ground to be 
used for analysis. In addition, this software must perform engineering calculations and save 
data for further analysis. 


Nomenclature 


ARO 

= 

Automated Rendezvous Officer 

CV 

= 

Capture Volume 

FRGF 

= 

Flight Releasable Grapple Fixture 

HTV 

= 

H-II Transfer Vehicle 

JAXA 

= 

Japanese Aerospace Exploration Agency 

/ 

= 

total corridor length 

MBS 

= 

Mobile Base System 

PI LOIB 

= 

Port 1 Lower Inboard 

PI LOOB 

= 

Port 1 Lower Outboard 

R 

= 

range 

RVS 

= 

Rendezvous Sensor 

RWS 

= 

Robotic Workstation 

SI LOOB 

= 

Starboard 1 Lower Outboard 

SpaceX 

= 

Space Exploration Technologies 

SSRMS 

= 

Space Station Robotic Manipulating System 

V 

= 

vehicle length/size 

VV 

= 

Visiting Vehicle 

WO 

= 

Visiting Vehicle Officer(s) 

X 

= 

corridor length 


I. Introduction 

The Automated Vehicles and Orbit Analysis Group (DM35) at the National Aeronautics and Space 
Administration (NASA) is responsible for performing orbit trajectory analysis on all visiting vehicle operations in 
the proximity of the International Space Station (ISS). This group has two front room Flight Control Positions: The 
Visiting Vehicle Officer (WO) and Automated Rendezvous Officer (ARO). When a Visiting Vehicle (VV) 
approach is in progress, a system of ISS mounted cameras are used to provide the ISS crew with real time video of 
the vehicle as it approaches the capture point. 

DM35 is primarily concerned, from a video monitoring perspective, with the following Visiting Vehicles: The 
Japanese Aerospace Exploration Agency’s (JAXA) H-II Transfer Vehicle (HTV), Space Exploration Technology 
Corporation’s (SpaceX) Dragon, and Orbital Science Corporation’s Cygnus. DM35 has appropriately denoted these 
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vehicles as “grapploid” Visiting Vehicles because the Space Station Robotic Manipulating System (SSRMS) will 
grapple with the vehicle’s Flight Releasable Grapple Fixture (FRGF) at a particular distance from the ISS prior to 
the berthing process. Once the robotics team has confirmed a good grapple with the FRGF, the SSRMS will then 
manipulate the vehicle to the appropriate ISS docking port. 

In order to ensure the vehicle approach process runs nominally, the respective owners of each grapploid Visiting 
Vehicle designed an imaginary three-dimensional corridor in space called the Crew Abort Corridor. The Crew 
Abort Corridor is a frustum, or a portion of a solid cut by two parallel planes, in this case a truncated pyramid. As a 
visiting vehicle closes the range between it and the ISS, the cross section of the Crew Abort Corridor decreases 
exponentially because the area in space for the vehicle to perform a safe abort decreases. The reasoning for this is 
because the area outside the Crew Abort Corridor violates flight rules for an abort and/or has not been fully analyzed 
for an abort scenario. In addition to nominal approach trajectory assurance, the Crew Abort Corridor also ensures 
that the Visiting Vehicle is on the right trajectory for the FRGF to be inside the Capture Volume (CV). The CV is 
the location in space where the SSRMS can safely grapple the FRGF when the vehicle is in Free Drift mode. The 
area outside the CV has been deemed unsafe for both vehicle Free Drift and SSRMS grapple. Therefore, it is of the 
upmost importance that each Visiting Vehicle stays inside the Crew Abort Corridor at all times during the 
approach/grappling process. 


II. Vehicle Approach Monitoring 1 

The ISS crew is responsible for monitoring the VV during its approach to the CV. This is done via the Robotic 
Workstation (RWS) in the Cupola and/or the backup RWS in the Lab. The RWS has three overhead monitors with 
live video feed from selected ISS exterior cameras. Each camera has the ability to pan, tilt, and zoom via the RWS 
Hardware Control Panel. For this vehicle approach 
monitoring, ISS Mobile Base System (MBS), 

Starboard 1 Lower Outboard (SI LOOB), Port 1 
Lower Outboard (PI LOOB), Port 1 Lower Inboard 
(PI LOIB), and Lab Cameras can be used in pairs. In 
addition to providing a live feed of the vehicle during 
an approach, the RWS monitors also generate overlays 
from data based on the Visiting Vehicle telemetry. 

The overlays are as follows 2 (in accordance to Figure 

1 ): 

1 . V ehicle T elemetry Data 

2. Crew Abort Corridor 

3. Vehicle Outline 

4. Vehicle Strobe Tracker 

5. ISS Velocity Vector 

6. Nested Corridor 

In an ideal vehicular approach, both the vehicle 
outline and actual vehicle image will be located in the 
center of the Crew Abort Corridor overlay. As a result 
of certain known errors, this may not always be the 
case. These errors include ISS camera biases and 
offsets, vehicle telemetry errors, or vehicle 
underperformance. In order for the source of these errors to be ascertained, both ISS crew and Mission Control 
Center (MCC) personnel must analyze the information provided through the RWS images and overlays. The main 
issue pertaining to this is that MCC has no way of directly seeing what the ISS crew is seeing on the 3 RWS 
monitors. (Software to duplicate the RWS functionality on the ground is in work but will not be available in time 
for upcoming VV flights.) There are, however, two indirect procedures which allow MCC to interoperate and 
analyze the data from the RWS: 

1. Direct KU Band Video Feed 

Direct KU band video provides MCC with a downlink of the video from the ISS. To view the RWS overlays, an 
“over-the- shoulder” camera would be mounted inside the Lab which views the RWS monitors. Video would then 
be down linked from ISS to MCC via KU band video communication wavelengths. There are, however, many 
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Figure 1. RWS Monitor Screenshot. Sample of one 
RWS monitor. Data and overlays based on vehicle 
telemetry. 
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problems associated with this particular approach, one being that scheduling of continuous KU assets is challenging. 
Secondly, the image quality tends to be poor as visual sharpness and integrity tends be lost while recording a 
monitor. 

2. ISS Crew Calls 

The second and more reliable way for MCC personnel to obtain RWS monitor information involves having the 
ISS crew call down exactly what they are seeing on the space-to-ground communication loop. Calls would then 
have to be made periodically to monitor the approach and spot any trends of the Visiting Vehicle during the berthing 
process. In order for this to become feasible, the WO team devised a concise and reliable way for the crew to 
describe the images and overlays seen on the RWS monitors. These calls are known as the Block B (Block 
“Bravo”) Crew Calls. 

A. Block B Crew Calls 

Standard Block B Crew Calls are divided into four distinct and important parts. First, the crew will confirm that 
the blinking white strobe light located on the VV is inside the Crew Abort Corridor. If it is not, both MCC 
personnel (particularly the VVOs) and ISS crew must take the necessary steps to ensure crew and vehicle safety. In 
the second part of the Block B call, the crew compares the physical size of the vehicle to the physical size of the 
Vehicle Outline overlay. This is done in terms of a percentage increase in size, percent decrease in size, or perfect 
size match. This is important because the relationship between the on-screen vehicle image and its outline can 
indentify whether the vehicle is closer or farther than what the telemetry is depicting. In the third and most 
important part of the Block B call, the ISS crew describes the vehicle’s white strobe light position in relation to the 
strobe tracker overlay, in terms of vehicle length and width. If discrepancies are found they can be attributed to one 
or more of the following possible errors: 

1. The VV is tracking the wrong place (reflector or other object) on ISS structure. 

2. The VV has a LIDAR angular bias. 

3. The ISS cameras being used for the RWS monitor displays have some sort of biases. 

VVOs can use trend monitoring to determine which errors are causing the discrepancies in the third section of 
each call by analyzing successive Block B calls during the approach. The call in part three compares the vehicle’s 
telemetry to the visual of the vehicle as seen from the RWS. If the approach monitoring relied solely on vehicle 
telemetry, many unforeseen errors could occur without crew or ground insight. In the fourth and final step in the 
Block B Crew Call, the crew describes the strobe tracker’s location relative to the center of the Crew Abort 
Corridor, which is also in terms of vehicular length and width. 

Vehicle white strobe and strobe tracker overlay offset directions are described in forward, aft, starboard, and port 
directions. These directions always correspond with the ISS velocity vector (as seen in Figure 1), regardless of the 
VV’s attitude. 

After each Block B call, the WO team is responsible for recording the data, analyzing it, and then taking any 
necessary action. WO team members would have to physically write down the data onto paper or enter the data 
into a computer spreadsheet. Team members would then perform preliminary analysis and angular offset 
calculations either by hand or via computational calculator. In order to perform trend monitoring, WO members 
would then draw the vehicle and the telemetric overlays per the Block B call (if necessary). This process of 
recording and analyzing the Block B data proved to be overly time consuming and tedious. 


III. Design of Visiting Vehicle Software Tool 

The main goal of this project was to develop a computer software tool in which MCC personnel, particularly 
VVOs, can easily input Block B Crew Call data which is voice communicated from the ISS crew members working 
at the RWS during a vehicle approach. The WO team member will use this tool for trend spotting, anomaly 
prediction, and data recording for future use and analysis. The VV tool was developed using Visual Basic for 
Applications 3 (VBA) and the program interface itself is run using Microsoft Excel. 

The VV tool consists of 10 separate Microsoft Excel spreadsheets: 

1. “START” 

2. “HTV - Cam 1” 

3. “HTV -Cam 2” 

4. “HTV Data” 

5. “Dragon - Cam 1” 
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6. “Dragon - Cam 2” 

7. “Dragon Data” 

8. “Cygnus - Cam 1” 

9. “Cygnus - Cam 2” 

10. “Cygnus Data” 

Upon opening the VV tool, each spreadsheet, with exception of “START,” will be hidden. On the “START” 
screen there are three separate command button user forms labeled HTV, Dragon, and Cygnus. The program user 
will select which Visiting Vehicle will be used for an approach simulation/mission. Once the appropriate command 
button is activated, the selected vehicle’s “Cam - 1” and “Data” spreadsheets become visible and active. The user is 
then ready to run the program per the given Block B Crew Calls. 

A. Crew Abort Corridor Dimension Calculations 

In order for the VV tool to best mimic the RWS 
overlays, the Crew Abort Corridor must appear to be the 
appropriate length and width at any given point during the 
approach. Each vehicle’s Crew Abort Corridor has set 
rectilinear dimensions (in meters) per vehicle range from 
the SSRMS Capture Volume. In addition to these 
dimensions, angular shifts in the +x, -x, +y, -y directions 
were also available for geometrical calculations 4 . Upon 
preliminary analysis, it became clear that overall Crew 
Abort Corridor size increased as VV range increased, 
which was expected. As shown in Figure 2, Crew Abort 
Corridor geometric analysis can be used to determine the 
following: (1) 

l = x + 2R tan 8 

Equation 1 is used to describe the corridor side length 
for any Visiting Vehicle at any given range, assuming a 
symmetric corridor. By implementing Equation (1) into 
preset vehicle Crew Abort Corridor dimensions, corridor 
length can easily be calculated. 

For program interface simplicity, corridor sizes remain constant as vehicle graphic lengths and widths increase 
appropriately, creating the illusion that the Crew Abort Corridor is dynamically changing. Known vehicular length 
values are then divided by Equation (1). Original corridor lengths were then substituted as x to yielding a ratio 
between vehicle length and corridor length. Finally, these ratios were graphed against an array of ranges. Best fit 
power equations were determined for all three vehicles as a result of this graphical analysis: 


x 



Figure 2. Crew Abort Corridor Geometry. Where x 
denotes original corridor length and R denotes vehicle 
range. 


v = 5.3675 + R-- 798 

(2a) 

v = 3.8953 + R-- 739 

(2b) 

v = 1.5210 + R~ 1S1 

(2c) 


Equations 2a, 2b, and 2c all denote the vehicle sizes, v, of HTV, Dragon, and Cygnus, respectively. As the range 
value, R , increases, vehicle size decreases appropriately. By incorporating this equation into the program code and 
multiplying its value by the corridor graphic size, Visiting Vehicle length will be sized as seen on the RWS 
monitors. Default VV length to with ratios were then added to the program code in order to ensure the vehicle 
graphic aspect ratio remains constant at any inputted range. 

B. Vehicle Angular Offset Calculations 5 

In order for there to be a nominal Visiting Vehicle berthing process, the vehicle must be within the Capture 
Volume during Free Drift for SSRMS grapple. The CV itself is a three dimensional volume in space located at the 
end of the Crew Abort Corridor. Due to the fact that the Capture Volume is not a finite point, vehicle offsets from 
the center of the corridor can be tolerated, to a certain extent. It is of the upmost importance that the WO team 
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Camera Fixed Biases 


monitors Block B calls throughout the entire approach to ensure the 
vehicle is trending towards the correct capture location. 

Each ISS camera used during the approach has distinct pan and tilt 
angular errors which were predetermined via testing. These individual 
errors are usually eliminated by camera calibration processes prior to 
Visiting Vehicle approach. In addition to these known camera biases, 

NASA engineers have also characterized camera biases based on 
uncontrollable anomalies, which can be seen in Figure 3. The Visiting 
Vehicle Software Tool has incorporated these know offsets into its 
coding for Capture Volume analysis. 

Certain vehicular angular offsets 
will occur in the event that the white 
strobe light on the approaching vehicle 
is not in line with the strobe tracker 
overlay. For simple analysis these 
angles can be calculated in the 
Forward/ Aft and Starboard/Port 
directions. The exact angular offsets 
can then be calculated because Block B 
call offsets are in terms of vehicle 
dimensions, which are known. The 
direction of the vehicle’s shift is 
perpendicular to the range, creating a 
right triangle, thus angular offsets can 
be easily calculated using simple 
trigonometry (See Figure 4). In the VV 
Tool, these calculated angular offsets are 

compared to the known biases from Figure 3 (which have been converted from pan 
and tilt offsets to Forward/ Aft and Starboard/Port directional offsets). The 
interface will give a warning to the user in the event the calculated angular offset 
exceeds the Capture Volume limits. With this information, WO team members can take proper action to ensure the 
VV will be at an acceptable capture location. 



Range 


SI LOOB Fixed Bias Pan 

+ 2.0 deg 

SI LOOB Fixed Bias Tilt 

- 0.2 deg 

PI LOIB Fixed Bias Pan 

+ 2.5 deg 

PI LOIB Fixed Bias Tilt 

- 1.3 deg 

MBS Fixed Bias Pan 

- 2.6 deg 

MBS Fixed Bias Tilt 

+ 0.7 deg 

PI LOOB Fixed Bias Pan 

+ 0.6 deg 

PI LOOB Fixed Bias Tilt 

-0.1 deg 

Capture Volume Error Sources 

ISS Thermal deformations 

+/- 0.20 
deg 

ISS Structural flex 

+/- 0.28 
deg 

ISS Attitude knowledge 

+/- 0.50 
deg 

ISS Attitude control accuracy 

+/- 0.80 
deg 

ISS Mechanical misalignment 

+/- 0.96 
deg 

ISS Margin under USOS control 

+/- 0.66 
deg 

ISS New RWS Quaternion SW 
Bug 

+/- 0.06 
deg 

Cam Error Range Pan 

+/- 2.0 
deg 


Cam Error Range Tilt 


+/- 0.8 
deg 


Figure 3. 
Sources 


Camera Biases and Error 


Figure 4. Vehicular Angular 
Offset. 


C. Visiting Vehicle Tool Trend Monitoring 

An important aspect of the Visiting Vehicle Software is Block B trend monitoring and evaluation. The VV 
program allows users to view previous Block B Crew Calls throughout the entire approach process. By way of the 
software tool, the user can easily view previous Block B vehicle images and outlines at will. With this important 
feature, WO team members can then determine what errors, if any, are present by way of trend evaluation. 


IV. Visiting Vehicle Software Tool Layout 

It was determined that the Visiting Vehicle tool must ensure that any user at MCC could generate an image based 
on the ISS crew Block B call in a quick and concise manner. Additionally, the tool must perform preliminary 
analysis calculations and analyze trends. Therefore it was designed to have a “user friendly” interface with many 
various features. 


Johnson Space Center 


6 


August 5, 2011 


NASA USRP - Internship Final Report 



Figure 5. Visiting Vehicle Tool User Interface. Red outlines and lettering are for reference only and are not 
included in the actual program user interface. Detailed explanation of the interface design can be found below. 

A. Range Input 

Vehicular range from ISS is inputted per Block B Crew Call. Inputted numerical contents are then used for 
various coded calculations for the VV software tool. 

B. Vehicular Outline Input 

Per Block B call, the program user has the option to input the appropriate vehicular size with respect to the 
outline size in terms of a percentage. Program user has the option to enter the numerical percentage value and then 
select either or “=”. The vehicle image will then be sized automatically depending on the size change 

selection and numerical value inputted. 

C. Vehicular Offset Interface 

The Vehicular Offset Interface allows the user to input all data associated with the Visiting Vehicle’s strobe light 
and strobe tracker’s location. Numerical data is inputted in terms of VV lengths and widths as heard via the Block B 
call. The interface then allows the user to set the graphic’s location by way of Forward/Aft and Starboard/Port 
directional vectors. If the ISS crew confirms certain parameters of the vehicle white strobe or strobe tracker are 
centered, then the user also has the option to input this information to the program. 

D. Camera Calibration Selection 

In the likely event that ISS cameras have been calibrated, the program user has the option to confirm this with 
the VV software tool. The program will then ignore certain individual angular biases based on the cameras having 
been calibrated, and conversely incorporate them into the mathematical calculations if they have not been calibrated. 

E. Camera Selection 

The camera selection box allows the program user to choose the active camera for the current Block B Crew 
Call. This ensures that the correct uncalibrated angular biases are incorporated into the VV software tool’s 
mathematical calculations. 
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F. Angular Offsets 

Calculated angular offsets are displayed in both the Forward/Aft and Starboard/Port directions. In the event that 
the vehicle angular offsets violate Capture Volume limits, the actual text in the angle display box will turn red. The 
threshold in which the program turns this text from standard black to red is governed by the known camera biases 
and capture volume errors. 

G. RVS Telemetry 

The user has the option of inputting RVS x, y, and z telemetric values. The software will then auto calculate all 
the angular offsets and capture volume errors, turning the display text red to indicate RVS capture volume threshold 
violation. 

H. Refreshing Graphics, Exporting Data, Adding Additoinal Cameras, and Resetting the Program 

The “Refresh Image” command will automatically generate the images and overlays as seen in the RWS 
monitors when the program user is satisfied with the inputted data. The “SUBMIT CALL” command button will 
automatically transfer all data pertaining to the previous Block B Crew Call to the appropriate Visiting Vehicle data 
sheet for future evaluation. In the event that the ISS crew is noting different visuals in the 2 RWS cameras during a 
Block B call, there is an option to load a new VV Tool Interface screen for dual camera monitoring. The “Reset All 
Calls” command button will reset all previous trend monitoring aspects of the software tool in the event that the user 
would like to start the approach monitoring process over without closing the program. 

I. Trend Monitoring 

For trend monitoring, the program user has the option of turning on all or any of the previous Block B call 
graphics and vehicle outlines. Upon doing so, the images will appear in the graphical display. 

J. Visiting Vehicle Software Tool Graphical Display 

The graphical display mimics the RWS monitors via the Block B Crew Call data inputted into the program user 
interface. 


V. Conclusion 

Visiting Vehicle Officers as well as Mission Control personnel need to have efficient means of obtaining data 
and solving problems as nearly all aspects of every spaceflight mission are time sensitive. Therefore, the 
development of a Visiting Vehicle Software Tool for HTV, Dragon, and Cygnus approach and grappling to ISS was 
of the upmost importance. This project, and the rationale behind its development, are perfect examples of why the 
National Aeronautics and Space Administration strives to perfect the way the crew in space communicates with 
MCC ground controllers. 

One important lesson NASA has learned via all its past endeavors is that there is always room for improvement 
and innovation. With the Space Shuttle Program coming to an end, NASA is relying on other space agencies and 
civilian companies for future ISS transportation operations. 

The Visiting Vehicle tool is a great success in that it provides the services it was set out to do and was completed 
in the allotted timeframe. The software tool has passed testing in various simulations and its future looks promising 
as a valuable asset for use in NASA Mission Control. 
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